Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/urn/urn-archives/urn-ietf.archive.9611/000198_owner-urn-ietf _Tue Nov 26 05:27:29 1996.msg

Internet Message Format | 1997-02-19 | 6KB

Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id FAA06514 for urn-ietf-out; Tue, 26 Nov 1996 05:27:29 -0500
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id FAA06509 for <[e-mail]>; Tue, 26 Nov 1996 05:27:14 -0500
Received: from [132.146.5.1] by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
        id AA12468  (mail destined for [e-mail]); Tue, 26 Nov 96 05:27:11 -0500
Received: from mailhub.axion.bt.co.uk by zaphod.axion.bt.co.uk with SMTP (PP); Tue, 26 Nov 1996 10:26:29 +0000
Received: from kaa.jungle.bt.co.uk by mailhub.axion.bt.co.uk with SMTP (PP); Tue, 26 Nov 1996 10:26:06 +0000
Received: from by kaa.jungle.bt.co.uk; Tue, 26 Nov 96 10:24:45 GMT
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 26 Nov 1996 10:27:39 +0000
To: Fisher Mark <[e-mail]>
From: Bob Briscoe <[e-mail]>
Subject: Re: [URN] Persistence as part of URN framework
Cc: "[e-mail]" <[e-mail]>,
        "[e-mail]" <[e-mail]>
Sender: [e-mail]
Precedence: bulk
Reply-To: Bob Briscoe <[e-mail]>
Errors-To: [e-mail]

Mark,

Many apologies for such a long time replying. I had to get some work
delivered, which translates to "ignore mailing lists".

All I wanted was an *optional* persistence value to be possible, so that the
URN resolution service could indicate the longevity of the resolver (not the
URN), at least until the longevity was extended once the people managing it
were willing to commit to a longer running service.

If the people running the resolver weren't willing to think about
persistence, a default longevity value of 0 could be sent out in the NAPTR
records.

However, I can find no-one else who considers this important, so I'll drop out.

I've been off-line with Ron Daniel who is happy that schemes such as HTTP
which have expiry headers can get this information to you once you have
resolved how to speak to HTTP.

No-one seems to be able to get their head round the fact that such expiry
times are meaningless if you don't know how long you will be able to resolve
URNs which end up pointing to HTTP, but might point to another scheme later
to keep them alive. I think the problem is that people just aren't thinking
in terms of how much the world will change in the decades ahead. All I'm
trying to propose is a way to avoid having to poll for broken resolution
services in the future.

I give up.

Bob

At 09:53 07/11/96 EST, Fisher Mark wrote:
>
>>Using DNS TTL records for this is just broken; DNS TTLs are used
>>to limit caching of name->address mapping, and in the NAPTR proposal,
>>they should be a fraction of the time one expects to have advance
>>warning of a server relocation or mapping restructure.
>>Normal TTLs are on the order of 3 days, and are usually reduced to less
>>than 1 day before serious network reorganizations.
>
>And if you are changing your resolution services faster than that, you are
>changing them too fast (IMHO).  Perhaps the key idea TimBL came up with in
>devising the Web was that, unlike other hypertext systems (including the
>Dexter model), links could be broken, i.e. nonfunctional.  This single idea
>was perhaps above all others important in spreading the Web far and wide, as
>perfectly reliable systems as difficult to construct (even for an
>appropriately low value of "perfect").  Under the Dexter model, an
>application will die or limp on after reporting an internal error upon
>encountering a broken hyperlink.  In the Web, the UA just keeps surfing on
>to the next link.
>
>All that URNs can do is assist in persistence; persistence itself must be
>maintained outside the URN architecture, as persistence is ultimately a
>political/economic quality, not a technical quality.  We would expect a BT
>URN to persist because of our trust in BT, not because there is some
>technical solution to persistence.  Persistence is assisted in URNs by the
>ability to hand off resolution duties automagically to successor resolution
>entities.  I would regard measures of persistence to be an optional but
>necessary part of the metadata for a URN, not as mandatory metadata.  It is
>quite possible that URN will see incredibly wide use, as much or more as
>URLs are now ("every person a URN namespace owner").  Many of these
>namespaces may just persist for a few years or months, with the owner not
>caring about measures of persistence.  Persistence is ultimately up to the
>creating/resolving entity(s).
>
>Uniqueness is an easier problem than persistence, although uniqueness has a
>strong political/economic component.  One can certainly imagine the case of
>URNs for government materials that, after they are first created for public
>consumption, are found to be embarrassing to that government and the URNs
>are silently, suddenly changed to refer to much more innocuous materials.
> Uniqueness, also, is ultimately up to the creating/resolving entity.
>======================================================================
>Mark Leighton Fisher                   Thomson Consumer Electronics
>[e-mail]                   Indianapolis, IN
>
>